In some secure communication protocols, not all parameters necessary for packet decryption are transmitted along with the packets. For example, in the secure real-time transport protocol (SRTP) as described in the Internet Engineering Task Force and the Internet Society, Request for Comment (RFC) 3711 entitled, “The Secure Real Time Transport Protocol,” the roll-over-count (ROC) parameter of the sequence number (SEQ) is not transmitted by the encryption device to the decryption device for each packet. To properly decrypt each SRTP packet received, the decryption device must correctly estimate the ROC that was used when the packet was encrypted.
While in many scenarios estimating the ROC isn't too difficult (see for example, the explanation of how to estimate ROC for SRTP received messages provided in RFC 3711, section 3.3.1), there are a number of other scenarios where estimating the correct ROC to use for a given received packet is very complicated and can often result in the loss of ROC/SEQ synchronization when the estimated ROC value does not match the actual ROC value for the received packet. For example, in some cases where there is a redundant configuration such as in the case where an active server is processing many thousands of Voice Over Internet (VOIP) secure calls being streamed using SRTP and the active server is backed up by a standby server that is to take over processing the calls if the active server partially or fully fails, some per call states, such as ROC/SEQ needs to be mirrored frequently from the active server to the standby server for each of the many thousands of secure calls being processed by the active server. If the mirroring isn't done sufficiently well, the standby server will not be able to maintain every secure call after it takes over. Other exemplary scenarios that are complicated from the perspective of estimating the ROC/SEQ are scenarios wherein SRTP is used for streaming secure calls and a call is placed on hold and then resumed or a re-invite sequence is sent. In some of these scenarios, the decryption device receiving the packets can get out of sync with the encryption side resulting in lost or one-way audio after the caller tries to resume the call such as after the call had been placed on hold.
Maintaining ROC/SEQ synchronization between encrypting devices and decrypting devices is especially challenging where active and standby servers are used and complex and frequent mirroring of estimated ROC/SEQ values is required. In such instances when the synchronization is lost due to an incorrect ROC estimated value the consequences can be severe such as for example the loss of an active call.
In view of the above, there is a need for new methods and apparatus for maintaining decryption state information such as for example, ROC parameter of the cryptographic context of an SRTP stream, with remote encryption state information for use with secure communication protocols such as for example SRTP.